Chapter 1. AI 기반 소프트웨어 개발의 패러다임 변화와 비결정성(Nondeterminism)의 한계

1. 서론: 소프트웨어 엔지니어링의 구조적 전복과 위기

소프트웨어 공학의 역사는 제어 가능성(Controllability)과 추상화(Abstraction) 사이의 끊임없는 투쟁이었다. 초기 천공 카드 시절부터 현대의 객체 지향 프로그래밍에 이르기까지, 엔지니어링의 핵심 목표는 인간의 의도를 기계가 이해할 수 있는 결정론적 논리(Deterministic Logic)로 변환하고, 그 실행 결과를 완벽하게 예측하는 것이었다. 그러나 거대 언어 모델(Large Language Model, LLM)의 등장과 함께 소프트웨어 개발의 패러다임은 근본적인 구조적 전복(Structural Inversion)을 맞이했다. 우리는 지금 명시적인 명령(Command)의 시대에서 모호한 의도(Intent)와 확률적 생성(Probabilistic Generation)의 시대로 진입하고 있다.

이러한 변화는 Andrej Karpathy가 주창한 Software 1.0에서 Software 2.0, 그리고 최근의 Software 3.0으로의 이행으로 설명될 수 있다. 과거의 프로그래머가 모든 논리적 분기(Branching)를 직접 통제했다면, 현대의 AI 엔지니어는 데이터의 흐름과 모델의 가중치, 그리고 자연어 프롬프트를 통해 시스템을 ’설득’한다. 이는 생산성의 비약적인 향상을 가져왔으나, 동시에 소프트웨어 신뢰성(Reliability)의 근간인 ’결정론적 재현성(Deterministic Reproducibility)’을 위협하는 심각한 기술적 부채를 야기하고 있다.

본 장에서는 AI 기반 소프트웨어 개발이 가져온 패러다임의 변화를 심층적으로 분석하고, 특히 LLM이 내재적으로 지닌 비결정성(Nondeterminism)의 기술적 원인을 규명한다. 또한, 이러한 비결정성이 전통적인 소프트웨어 테스트의 핵심 개념인 ’오라클(Oracle)’을 어떻게 붕괴시키는지, 그리고 엔터프라이즈 환경에서 신뢰할 수 있는 AI 시스템을 구축하기 위해 해결해야 할 과제가 무엇인지 논한다.

2. 소프트웨어 패러다임의 진화: 결정론적 논리에서 확률적 의도로

소프트웨어 개발의 진화는 단순히 도구의 발전이 아니라, 문제 해결을 위한 사고방식(Mindset)과 접근 방법의 근본적인 이동을 의미한다.

2.1 Software 1.0: 명시적 제어와 환원주의적 접근

Software 1.0은 고전적인 프로그래밍 패러다임이다. Python, C++, Java 등의 언어를 사용하여 개발자가 문제 해결을 위한 모든 절차를 명시적으로 기술한다. 이 방식은 환원주의적(Reductionist)이다. 복잡한 문제는 더 작은 문제로 분해되고, 각 부분은 명확한 알고리즘으로 구현된다.

특징: 코드(Code)가 동작을 정의한다. 논리는 투명하며, 디버깅이 가능하다.
결정론: 하드웨어 오류가 없다면 동일한 입력은 항상 동일한 출력을 보장한다.
한계: 이미지 인식이나 자연어 처리와 같이 규칙으로 명시하기 어려운 복잡한 문제에는 적용하기 어렵다.

2.2 Software 2.0: 데이터 중심의 최적화와 블랙박스화

Software 2.0은 딥러닝(Deep Learning)의 부상과 함께 등장했다. Karpathy에 따르면, Software 2.0에서 개발자는 알고리즘을 직접 작성하지 않는다. 대신 원하는 동작을 나타내는 데이터셋(Dataset)을 구축하고, 신경망 구조(Architecture)를 설계한다. 프로그램의 실체는 수백만, 수십억 개의 가중치(Weights) 집합이다.

특징: 데이터가 곧 코드다. 최적화(Optimization) 과정이 컴파일을 대체한다.
추상화: 인간이 이해하기 어려운 추상적인 수학적 공간에서 프로그램이 동작한다.
비결정성의 시작: 학습 과정의 무작위성(Randomness)과 데이터의 편향(Bias)이 결과에 영향을 미치기 시작한다.

2.3 Software 3.0: 자연어 프로그래밍과 비결정성의 보편화

Software 3.0은 거대 언어 모델(LLM)을 범용 컴퓨팅 엔진으로 활용하는 단계다. 이제 개발자는 모델을 학습시키는 것을 넘어, 이미 학습된 모델에게 자연어(Natural Language)로 지시(Prompting)를 내린다.

특징: 자연어가 프로그래밍 언어가 된다. 진입 장벽이 낮아지지만, 통제력 또한 약화된다.
비결정성의 극대화: 모델의 출력은 확률 분포에 기반하여 생성되므로, 미세한 변화(프롬프트의 단어 순서, 띄어쓰기 등)에도 결과가 달라질 수 있다.
위험 요소: 환각(Hallucination) 현상과 논리적 불일치가 발생할 수 있으며, 이는 소프트웨어의 신뢰성을 위협하는 가장 큰 요인이 된다.

3. AI 시스템의 비결정성(Nondeterminism)에 대한 기술적 해부

많은 개발자들과 기업들이 AI를 도입하면서 겪는 가장 당혹스러운 경험은 “어제 잘 동작하던 프롬프트가 오늘 실패하는” 현상이다. 흔히 temperature=0으로 설정하면 모델이 결정론적으로(Deterministic) 동작할 것이라 기대하지만, 이는 기술적 오해에 불과하다. LLM의 비결정성은 단순한 하이퍼파라미터 설정의 문제가 아니라, 현대 컴퓨팅 아키텍처와 부동소수점 연산의 본질적인 특성에서 기인한다.

3.1 하드웨어 수준의 비결정성: GPU와 부동소수점 연산

현대 AI 모델의 추론(Inference)은 대규모 병렬 처리가 가능한 GPU(Graphics Processing Unit) 위에서 수행된다. GPU는 수천 개의 코어를 사용하여 행렬 연산(Matrix Multiplication)을 수행하는데, 이 과정에서 부동소수점 연산의 비결합성(Non-associativity) 문제가 발생한다.

수학적으로 실수의 덧셈은 결합 법칙이 성립한다. 즉, $(a + b) + c = a + (b + c)$ 이다. 그러나 컴퓨터가 사용하는 부동소수점(IEEE 754 표준) 연산에서는 유효숫자의 제한(Precision limits)과 반올림 오차(Rounding error)로 인해 연산 순서에 따라 결과가 미세하게 달라진다.
$\text{Floating Point Operation:} \quad (a \oplus b) \oplus c \neq a \oplus (b \oplus c)$
여기서 $\oplus$ 는 부동소수점 덧셈 연산을 의미한다. GPU는 병렬 처리를 극대화하기 위해 수많은 스레드(Thread)가 동시에 연산을 수행하고 결과를 합산(Reduction)한다. 이때 각 스레드가 작업을 완료하고 합산에 참여하는 순서는 GPU의 스케줄링, 온도, 전력 상태, 런타임 환경에 따라 매번 달라질 수 있다. 이를 ’원자적 덧셈(Atomic Add)’을 이용해 처리할 경우, 더해지는 순서가 무작위로 바뀌며, 이는 최종 결과값의 비트 단위(Bitwise) 차이를 유발한다. LLM과 같이 수십억 번의 연산이 누적되는 시스템에서 이러한 미세한 오차는 나비 효과(Butterfly Effect)를 일으켜 완전히 다른 토큰(Token)이 선택되게 만들 수 있다.

3.2 소프트웨어 스택의 비결정성: 병렬 처리와 동적 최적화

하드웨어뿐만 아니라 딥러닝 프레임워크와 추론 엔진 수준에서도 비결정성이 발생한다.

동적 커널 선택(Dynamic Kernel Selection): PyTorch나 TensorFlow와 같은 프레임워크는 실행 시점의 입력 크기나 하드웨어 상태에 따라 최적의 연산 알고리즘(Kernel)을 동적으로 선택한다. 같은 입력이라도 내부적으로 다른 알고리즘이 선택되면 연산 순서가 바뀌어 결과가 달라질 수 있다.
배치 처리(Batching)의 영향: 추론 효율을 높이기 위해 여러 요청을 묶어 처리하는 과정(Batch Inference)에서도 문제가 발생한다. 단일 요청을 처리할 때와 16개의 요청을 묶어 처리할 때, 메모리 레이아웃과 연산 패턴이 달라진다. 연구 결과에 따르면, 배치 크기(Batch Size)가 변경되는 것만으로도 동일한 모델, 동일한 입력에 대해 다른 출력이 생성될 수 있음이 확인되었다. 이는 ’배치 불변성(Batch Invariance)’이 깨진 상태로, API 서비스 사용자가 통제할 수 없는 영역이다.

3.3 모델 아키텍처의 비결정성: MoE와 샘플링 전략

최신 LLM들이 채택하고 있는 혼합 전문가(Mixture-of-Experts, MoE) 아키텍처는 비결정성을 심화시킨다. MoE 모델은 입력 토큰을 라우터(Router)를 통해 특정 전문가 네트워크로 분배한다.

로드 밸런싱과 토큰 드롭: 특정 전문가에게 부하가 몰릴 경우, 로드 밸런싱을 위해 토큰이 다른 전문가로 라우팅되거나 드롭(Drop)될 수 있다. 이는 시스템의 전체 부하 상태라는 외부 요인이 개별 요청의 처리 경로를 변경함을 의미한다.
샘플링 파라미터: Top-p, Top-k 등의 샘플링 전략은 확률적 선택을 전제로 한다. Temperature=0은 가장 높은 확률의 토큰을 선택하는 탐욕적(Greedy) 디코딩을 의미하지만, 앞서 언급한 하드웨어 및 소프트웨어적 요인으로 인해 로짓(Logit) 값 자체가 미세하게 변동하면, 1위와 2위 토큰의 순위가 뒤바뀔 수 있다.

4. 오라클 문제(The Oracle Problem)의 재정의

소프트웨어 테스팅에서 ’오라클(Oracle)’이란 시스템의 실행 결과가 올바른지 판단하는 메커니즘을 의미한다. 전통적인 소프트웨어 테스팅은 입력 $x$ 에 대해 기대 출력 $y$ 가 명확히 정의된 상태에서 수행된다. 그러나 AI 기반 소프트웨어 개발, 특히 생성형 AI의 도입은 이 오라클의 개념 자체를 뒤흔들고 있다.

4.1 고전적 오라클의 붕괴

Software 1.0 환경에서 오라클은 주로 ’명세 기반(Specified)’이거나 ’회귀 기반(Derived)’이었다.

명세 기반 오라클: “입력이 A이면 출력은 B여야 한다“는 명확한 규칙이 존재한다.
회귀 기반 오라클: 이전 버전의 소프트웨어가 생성한 결과를 정답으로 간주하고 비교한다.

하지만 Software 3.0에서는 이러한 오라클이 작동하지 않는다.

정답의 부재: “매력적인 마케팅 문구를 작성하라“는 요청에 대해 단 하나의 정답은 존재하지 않는다. 이는 ’오라클 문제’를 ’평가 문제(Evaluation Problem)’로 전환시킨다.
출력의 다양성: 동일한 프롬프트에 대해 모델은 매번 다른 표현, 다른 구조의 텍스트를 생성할 수 있다. 단순한 문자열 비교(String Matching)는 더 이상 유효한 검증 수단이 아니다.
검증 불가능한 복잡성: 모델이 생성한 코드나 법률적 조언이 겉보기에는 완벽해 보이지만, 실제로는 미묘한 논리적 오류나 허위 사실을 포함하고 있을 수 있다. 이를 검증하기 위해서는 모델보다 더 뛰어난 지능이나 도메인 지식이 필요하다.

4.2 확률적 출력과 검증 비대칭성 (Verification Asymmetry)

AI 개발의 핵심적인 경제적 딜레마는 ’생성 비용’과 ’검증 비용’의 극심한 비대칭성에서 온다.

생성(Generation): LLM은 단 몇 초 만에 수천 줄의 코드나 장문의 보고서를 생성할 수 있다. 비용은 매우 낮다.
검증(Verification): 생성된 결과물이 정확한지 확인하려면 인간 전문가가 직접 검토하거나, 복잡한 테스트 케이스를 실행해야 한다. 비용은 매우 높다.

이러한 비대칭성은 소프트웨어 개발 프로세스에 병목 현상을 일으킨다. Karpathy가 언급했듯이, Software 2.0/3.0 프로그래머의 역할은 코드를 작성하는 것에서 데이터를 큐레이션하고 결과를 검증하는 것으로 이동한다. 그러나 검증 도구가 생성 속도를 따라가지 못할 때, 개발 속도는 오히려 저하되거나, 검증되지 않은 코드가 배포되는 위험을 초래한다.

4.3 AI 개발에서의 오라클 부재가 초래하는 리스크

오라클의 부재는 단순한 불편함을 넘어 실질적인 리스크로 이어진다.

사일런트 페일리어(Silent Failure): 전통적인 소프트웨어는 버그가 있으면 크래시(Crash)되거나 에러 메시지를 낸다. 반면, AI 모델은 확신에 찬 어조로 틀린 답을 내놓는다(Hallucination). 오라클이 없다면 이러한 오류는 프로덕션 환경에서 발견될 때까지 숨겨져 있게 된다.
회귀 테스트의 어려움: 모델을 업데이트하거나 프롬프트를 수정했을 때, 기존 기능이 유지되는지 확인하기 어렵다. 정량적인 오라클 없이는 모델 성능의 향상이나 저하를 객관적으로 판단할 수 없다.

5. AI 시스템의 숨겨진 기술 부채 (Hidden Technical Debt)

구글의 연구진이 발표한 “Hidden Technical Debt in Machine Learning Systems” 논문은 머신러닝 시스템이 갖는 독특한 기술 부채를 경고한다. 이는 Software 3.0 시대에 더욱 심화되고 있다.

5.1 CACE 원칙과 얽힘(Entanglement) 현상

전통적인 소프트웨어 엔지니어링은 ’관심사의 분리(Separation of Concerns)’와 모듈화를 통해 복잡성을 관리한다. 그러나 AI 시스템은 CACE(Changing Anything Changes Everything) 원칙이 지배한다.

얽힘(Entanglement): 입력 데이터의 분포가 변하거나(Data Drift), 하이퍼파라미터 하나가 바뀌면, 모델의 전체 동작이 예측 불가능한 방식으로 변한다. 특정 기능을 개선하기 위해 프롬프트를 수정했더니, 전혀 관련 없는 다른 기능에서 성능이 저하되는 현상이 비일비재하다. 이는 시스템의 격리(Isolation)를 불가능하게 만들며, 유지보수 비용을 기하급수적으로 증가시킨다.

5.2 데이터 의존성과 피드백 루프

AI 시스템은 코드보다 데이터에 더 강하게 의존한다.

불안정한 데이터 의존성(Unstable Data Dependencies): 외부 API나 사용자 로그와 같은 불안정한 데이터 소스에 의존할 경우, 소스의 변화가 시스템 전체의 품질 저하로 이어진다.
피드백 루프(Feedback Loops): 모델의 출력이 다시 모델의 학습 데이터로 사용되거나, 사용자의 행동에 영향을 미쳐 다시 입력 데이터의 분포를 바꾸는 현상이다. 이는 시간이 지남에 따라 모델의 편향을 강화하거나 성능을 저하시킬 수 있다.

5.3 접착 코드(Glue Code)와 파이프라인 정글

AI 모델을 기존 시스템에 통합하기 위해 수많은 ’접착 코드(Glue Code)’가 작성된다. 데이터 전처리, 후처리, 포맷 변환 등을 담당하는 이 코드들은 시스템의 복잡도를 높이고, 디버깅을 어렵게 만든다. 또한, 데이터 파이프라인이 복잡하게 얽히면서 ’파이프라인 정글(Pipeline Jungle)’이 형성되어, 데이터의 흐름을 추적하거나 수정하는 것이 거의 불가능해지는 상황이 발생한다.

6. 실전 사례 분석: 결정론적 오라클 부재의 대가

비결정성과 오라클의 부재는 이론적인 문제가 아니라 현실적인 재앙으로 나타나고 있다.

6.1 금융 및 법률 분야의 환각 오류와 규제 준수 실패

금융이나 법률 분야는 100%의 정확성과 재현성이 요구되는 영역이다. 그러나 확률적 모델의 도입은 심각한 사고를 유발했다.

법률 환각 사례: 미국의 한 변호사가 ChatGPT를 사용하여 판례를 검색했으나, AI가 존재하지 않는 가짜 판례를 생성하여 법원에 제출한 사건이 발생했다. 이는 AI의 출력을 검증할 오라클(검증 프로세스) 없이 맹신한 결과다. 법원은 이를 단순 실수가 아닌 전문가의 검증 의무 위반으로 간주하고 제재를 가했다.
금융 규제 위반: 금융 모델은 설명 가능성과 일관성이 필수적이다. 동일한 대출 신청자에 대해 AI 모델이 실행 시점마다 다른 신용 점수를 부여한다면, 이는 공정거래법 및 금융 규제를 정면으로 위반하는 것이다. 확률적 모델의 비결정성은 ’동일 대우’라는 법적 원칙과 충돌한다.

6.2 엔터프라이즈 환경에서의 검증 비용 폭발

기업들은 AI 도입으로 인건비를 절감할 것으로 기대했지만, 실제로는 검증 비용의 폭발을 경험하고 있다. 딜로이트(Deloitte)의 경우 AI를 활용한 프로젝트에서 품질 관리 실패로 인해 계약 불이행 및 평판 손실을 입었다. AI가 생성한 결과물을 전수 검사(Human-in-the-loop)하는 것은 비용 효율적이지 않다. 그렇다고 검사를 생략하면 리스크가 너무 크다. 결과적으로 기업들은 ‘자동화된 검증 오라클’ 없이는 AI 시스템을 확신을 가지고 배포할 수 없는 딜레마에 빠져 있다. 이는 AI 도입의 ROI(투자 대비 효과)를 급격히 떨어뜨리는 요인이 된다.

7. 결론: 결정론적 오라클 확보를 위한 과제

Software 3.0으로의 전환은 거스를 수 없는 흐름이다. 그러나 “확률적 도구로 결정론적 결과를 보장해야 하는” 역설은 여전히 해결되지 않은 난제다. 본 장에서 살펴본 바와 같이, AI의 비결정성은 하드웨어의 물리적 특성부터 소프트웨어 아키텍처까지 전 계층에 내재되어 있다. 따라서 단순히 모델의 성능을 높이는 것만으로는 이 문제를 해결할 수 없다.

우리는 새로운 형태의 오라클을 필요로 한다. 그것은 단순한 문자열 일치 여부를 확인하는 것을 넘어, **의미론적 유사성(Semantic Similarity)**을 평가하고, **구조적 정합성(Structural Integrity)**을 강제하며, 확률적 변동성을 통제할 수 있는 **‘결정론적 오라클(Deterministic Oracle)’**이어야 한다. 이러한 오라클의 구축은 AI 소프트웨어의 신뢰성을 확보하고, 기술 부채를 관리 가능한 수준으로 유지하기 위한 유일한 해법이다.

이어지는 장들에서는 이러한 오라클을 설계하고 구현하기 위한 구체적인 방법론들을 다룰 것이다. 프롬프트 엔지니어링을 통한 제어, 구조화된 출력의 강제, 그리고 정적 분석과 결합된 하이브리드 검증 시스템 등은 AI 개발의 불확실성을 통제 가능한 엔지니어링의 영역으로 끌어들이는 핵심 열쇠가 될 것이다.

8. 참고 자료

Software 2.0: An Emerging Era of Automatic Code Generation, https://blog.softtek.com/software-2.0-an-emerging-era-of-automatic-code-generation
Talk: Andrej Karpathy: Software Is Changing (Again) - Kyle Howells, http://ikyle.me/blog/2025/andrej-karpathy-software-is-changing-again
Software 2.0. I sometimes see people refer to neural… | by Andrej …, https://karpathy.medium.com/software-2-0-a64152b37c35
Andrej Karpathy on the Rise of Software 3.0 - Analytics Vidhya, https://www.analyticsvidhya.com/blog/2025/06/andrej-karpathy-on-the-rise-of-software-3-0/
Non-Determinism of “Deterministic” LLM System Settings in Hosted, https://aclanthology.org/2025.eval4nlp-1.12.pdf
Why Temperature=0 Doesn’t Guarantee Determinism in LLMs, https://mbrenndoerfer.com/writing/why-llms-are-not-deterministic
Defeating Nondeterminism in LLM Inference - Thinking Machines Lab, https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/
On the Structure of Floating-Point Noise in Batch-Invariant GPU, https://arxiv.org/html/2511.00025v1
Why is deterministic output from LLMs nearly impossible? - Unstract, https://unstract.com/blog/understanding-why-deterministic-output-from-llms-is-nearly-impossible/
arxiv.org, https://arxiv.org/html/2408.04667v5
Test oracle - Wikipedia, https://en.wikipedia.org/wiki/Test_oracle
(PDF) The Oracle Problem in Software Testing: A Survey, https://www.researchgate.net/publication/276255185_The_Oracle_Problem_in_Software_Testing_A_Survey
LLMs vs. Rule-Based Systems: Bridging AI with Deterministic Logic, https://blog.gopenai.com/llms-vs-deterministic-logic-overcoming-rule-based-evaluation-challenges-8c5fb7e8fe46
Leveraging law and ethics to promote safe and reliable AI/ML … - PMC, https://pmc.ncbi.nlm.nih.gov/articles/PMC11440832/
Hidden Technical Debt in Machine Learning Systems - NIPS, https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems
Hidden Technical Debt in Machine Learning Systems - NIPS, https://papers.neurips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf
Hidden Technical Debt in Machine Learning Systems, https://lathashreeh.medium.com/hidden-technical-debt-in-machine-learning-systems-27fa1b13040c
My Summary Of Hidden Technical Debt in Machine Learning Systems, https://colabdoge.medium.com/my-summary-of-hidden-technical-debt-in-machine-learning-systems-f680bf1337ad
Machine Learning: Hidden Technical Debts and Solutions, https://towardsdatascience.com/machine-learning-hidden-technical-debts-and-solutions-407724248e44/
What the Epidemic of AI Failures in Law Means for Professionals, https://www.joneswalker.com/en/insights/blogs/ai-law-blog/from-enhancement-to-dependency-what-the-epidemic-of-ai-failures-in-law-means-for.html?id=102l04x
When AI Becomes a Legal Liability: Why Probabilistic Models Fail, https://aijourn.com/when-ai-becomes-a-legal-liability-why-probabilistic-models-fail-compliance-and-how-deterministic-ai-restores-trust/
The Deloitte AI Failure: A Wake-Up Call for Operational Risk - Pirani, https://www.piranirisk.com/blog/the-deloitte-ai-failure-a-wake-up-call-for-operational-risk
The AI Integration Crisis: Why 95% of Enterprise Pilots Fail (and the, https://servicepath.co/2025/09/ai-integration-crisis-enterprise-hybrid-ai/